Apéndice A · PRD
Agente de WhatsApp para Socios Comerciales

1 Contexto de negocio

• 445 socios comerciales activos · 411 prospectos creados/mes · ~400 consultas sobre prospectos/mes.
• La atención actual se da por teléfono o WhatsApp personal de asesores internos, sin registro formal ni trazabilidad — no existe línea base de medición; el Feature 0 la construye.
• El agente opera como capa de autogestión sobre las plataformas existentes (Salesforce como fuente de verdad de prospectos/contratos/tickets, Nufi, S3), no como reemplazo.
• Alcance de escala confirmado: red actual de socios (~445). El auto-onboarding a mercado abierto es evolución futura, fuera de este programa.

2 Decisiones de producto validadas — sesión 2026-08-06

3 Proceso actual (as-is)

1. Consulta de estatus de prospecto/lead (hoy: llamada o WhatsApp personal al asesor).
2. Consulta de estatus de contrato/expediente (incl. SLA de activación).
3. Levantamiento y seguimiento de tickets (hoy sin registro formal).
4. Alta de prospecto por parte del socio/reseller.
5. Cotización y recotización (hoy: persona de BI genera cotizaciones ad-hoc vía workflow de Salesforce; aprobación del equipo de pricing).
6. Solicitud de guías, terminales y rollos; devoluciones y bajas.
7. Entrega de accesos y credenciales de equipos/terminales.
8. Solicitudes de capacitación.
9. Escalamiento a asesor humano (destino y horario a definir — hoy no existe bandeja formal).
10. Avisos operativos y comunicación a la red de socios.

4 Proceso esperado (to-be)

4.1 · Identificación y autorización

Identificación por número de celular registrado (bajo riesgo) + ID de Socio como segundo factor para datos sensibles (expedientes, contratos, datos de cuenta). Autorización Socio/Master ↔ cuenta/company/branch evaluada del lado servidor en cada consulta — nunca en el cliente ni en copias planas. Perfiles administradores con vista cruzada entre cuentas del corporativo. Toda consulta a datos queda en bitácora auditable.

4.2 · Consultas en autoservicio (Fase 1 — solo lectura)

El socio identificado consulta: prospectos y leads (estatus en funnel), contratos y expedientes, SLA de activación, tickets y su estatus. Respuestas con citación de fuente; ante información inexistente el agente lo dice explícitamente (no inventa).

4.3 · Conocimiento y postventa (Fase 1)

Base de conocimiento curada: requisitos, tiempos de vida, manual de crisis, productos. Captura y canalización de solicitudes de capacitación.

4.4 · Escalamiento humano (Fase 1)

Enrutamiento a asesores internos con transcripción y contexto de sesión. Horario definido y comportamiento fuera de horario. El destino (bandeja formal) se define en F0; la operación omnicanal plena llega con Amazon Connect en F9.

4.5 · Comunicación proactiva (Fase 1)

Notificaciones de SLA por vencer mediante plantillas de utilidad aprobadas por Meta, segmentadas. Avisos y funcionalidad de comunidad mediante difusión segmentada por listas administrada desde el agente (la API de WhatsApp Business no expone Comunidades nativas). Reglas de frecuencia, horario y consentimiento se acotan en F0.

4.6 · Gestión transaccional (Fase 2 — escritura)

Creación de prospectos, creación y seguimiento de tickets, solicitud de cambio de datos. Patrón obligatorio: confirmación explícita del usuario antes de escribir + idempotencia ante reintentos + bitácora y reversión de toda operación de escritura.

4.7 · Cotizador con IA (Fase 2 — capacidad angular)

1. El socio (o prospecto en calificación) proporciona contexto por WhatsApp: giro, volumen anual estimado, ticket promedio.
2. El agente — entrenado con la base histórica de cotizaciones aprobadas por pricing — genera una recomendación de condiciones comerciales (p. ej., tasa sugerida por giro/perfil), estilo wizard/sugerencia, sin necesidad de registrar formalmente un prospecto.
3. La recomendación opera dentro de piso y techo definidos por reglas de negocio. Dentro de límites: el agente entrega la cotización. Fuera de límites: lo comunica, genera ticket y escala a pricing para aprobación humana.
4. Entrega de la cotización: PDF o liga a presentación dinámica editable donde la conversación con el agente puede continuar fuera de WhatsApp (decisión D8, se resuelve con la POC).
5. Si el prospecto avanza: transición al alta formal (F5) y, en F9, al flujo integrado con Nufi (KYB), Mifiel (firma) y Captura Core.

POC previa (Feature 0): valida los pasos 1–4 con data real. Criterios de éxito: recomendación de tasa aproximada coherente con el histórico de pricing en ≥ N casos de prueba definidos conjuntamente; experiencia de interacción evaluada por el equipo de NetPay simulando el rol de reseller; fricciones documentadas con decisión sobre D8.

Requisito de data (insumo #8): extracto de cotizaciones aprobadas por pricing, 18–24 meses, con campos mínimos a acordar en F0 (giro, volumen, ticket promedio, condiciones aprobadas, fecha, resultado). Sin esta data no hay entrenamiento: la fecha de entrega gobierna la fecha de la POC y del F6.

4.8 · Entrenamiento continuo y estabilización

• Beta testers pre-liberación (D9) con data cercana a producción.
• Ramp-up de 3–4 semanas post-liberación: revisión de conversaciones reales, ajuste de prompts y contenido, incorporación de edge cases.
• Training mode: corrección en tiempo real por parte del equipo operador sin ciclo de release.

5 Catálogo de intents — v0, se prioriza y cierra en F0

6 No happy paths — obligatorios en Fase 1

1. Usuario sin permisos sobre el dato solicitado → respuesta de acceso denegado sin revelar existencia del dato + registro en bitácora.
2. Socio no encontrado / celular no registrado → ruta de verificación alterna con ID de Socio; si falla, escalamiento.
3. Dato inexistente → el agente lo declara explícitamente; nunca inventa.
4. Permisos revocados a media sesión → la siguiente consulta se re-autoriza server-side y se corta el acceso.
5. Pregunta fuera de dominio / tema personal → redirección amable al objetivo del canal (tono definido en F0).
6. Fallo de fuente (Salesforce/API caída) → mensaje de indisponibilidad honesto + reintento + alerta operativa.
7. Solicitud fuera de horario de escalamiento → captura del caso + compromiso de seguimiento en horario hábil.

7 Data readiness — checklist de entrada, se verifica en F0

8 Criterios de aceptación por feature

Los entregables listados por feature en la propuesta (sección 05) son los criterios de aceptación verificables. Adicionalmente, a los 90 días de liberada la Fase 1 se evalúan los KPIs de la sección 11 de la propuesta contra la línea base del Feature 0. La aceptación de entregables corresponde al dueño de negocio firmante de este PRD.

9 Backlog de evolución — registrado, sin compromiso

Firma de cierre — al término del Feature 0

Con la firma de este PRD queda congelado el alcance funcional de las Fases 1 y 2. Cambios posteriores: control de cambios con impacto en tiempo y costo.